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Introduction 


Following is a description of the Internet Clock 
Service (ICS) provided by all DCNET hosts. The service, 
intended primarily for clock synchronization and one-way 
delay measurements with cooperating internet hosts, is 
provided using the Timestamp and Timestamp Reply messages of 
the proposed Internet Control Message Protocol (ICMP). In 
addition, in order to maintain compatability with present 
systems, this service will be provided for a limited time 
using the Echo and Echo Reply messages of the 
Gateway-Gateway Protocol (GGP). 

It should be understood that ICMP and GGP datagrams are 
normally considered tightly bound to the Internet Protocol 
(IP) itself and not directly accessable to the user on a 
TOPS-20 system, for example. These datagrams are treated 
somewhat differently from user datagrams in gateways and 
DCNET hosts in that certain internal queueing mechanisms are 
bypassed. Thus, they can be a useful tool in providing the 
most accurate and stable time reference. The prime 
motivation for this note is to promote the development of 
this service in other internet hosts and gateways so that 
the feasibility for its use thoughout the community can be 
assessed. 


ICS Datagrams and Timestamps 


At present, the ICS is provided using either ICMP or 
GGP datagrams. The only difference between these is that 
ICMP uses protocol number 1 and GGP uses protocol number 3. 
In the following these will be referred to interchangably as 
ICS datagrams. ICS datagrams include an internet header 
followed by an ICS header in the following format: 
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+-+-+-+-+-+-+-+-+ 
| Type | Code | Sequence 
+ 


| Originate Timestamp 


4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4-4-4-4- 


| Receive Timestamp 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


| Transmit Timestamp 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


ICS Datagram Format 


The originator fills in all three timestamp fields just 
before the datagram is forwarded to the net. Each of these 
fields contain the local time at origination. Although the 
last two are redundant, they allow roundtrip delay 
measurements to be made using remote hosts without 
timestamping facilities. The "Type" field can be either 8 
(GGP Echo) or 13 (ICMP Timestamp). The "Code" field should 
be zero. The "Sequence" field can contain either zero or an 
optional sequence number provided by the user. The length 
of the datagram is thus 36 octets inclusive of the 20-octet 
internet header and exclusive of the local-network leader. 


The host or gateway receiving an ICS datagram fills in 
the "Receive Timestamp" field just as the datagram is 
received from the net and the "Transmit Timestamp" just as 
it is forwarded back to the sender. It also sets the "Type" 
field to 0 (GGP Echo Reply), if the original value was 8, or 
14 (ICMP Timestamp Reply), if it was 13. The remaining 
fields are unchanged. 


The timestamp values are in milliseconds from midnight 
UT and are stored right-justified in the 32-bit fields shown 
above. Ordinarily, all time calculations are performed 


modulo-24 hours in milliseconds. This provides a convenient 
match to those operating systems which maintain a system 
clock in ticks past midnight. The specified timestamp unit 


of milliseconds is consistent with the accuracy of existing 
radio clocks and the errors expected in the timestamping 
process itself. 


Delay Measurements 


Delay measurements can be made with any DCNET host by 
simply sending an ICS datagram in the above format to it and 
processing the reply. Let tl, t2 and t3 represent the three 
timestamp fields of the reply in order and t4 the time of 
arrival at the original sender. Then the delays, exclusive 
of internal processing within the DCNET host, are simply 
(t2 - t1) to the DCNET host, (t4 - t3) for the return and 
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(t2 - t1) + (t4 - t3) for the roundtrip. Note that, in the 
case of the roundtrip, the clock offsets between the sending 
host and DCNET host cancel. 


Although ICS datagrams are returned by all DCNET hosts 
regardless of other connections that may be in use by that 
host at any given time, the most useful host will probably 
be the COMSAT-WWV virtual host at internet address 
[29,0,9,2], which is also the internet echo virtual host 
formerly called COMSAT-ECH. This virtual host is resident 
in the COMSAT-GAT physical host at internet address 
[29,0,1,2], which is connected to the ARPANET via the COMSAT 
Gateway, Clarksburg SIMP and a 4800-bps line to IMP 71 at 
BBN. The roundtrip delay via this path between the 
COMSAT-GAT host and the BBN Gateway is typically 550 
milliseconds as the ICS datagram flies. 


As in the case of all DCNET hosts, if the COMSAT-WWV 
virtual host is down (in this case possible only if the 
Spectracom radio clock is down or misbehaving) a "host not 
reachable" GGP datagram is returned. In unusual 
circumstances a "net not reachable" or "source quench" GGP 
datagram could be returned. Note that the references to 
"GGP" here will be read "ICMP" at some appropriate future 
time. 


Local Offset Corrections 


All DCNET timestamps are referenced to a designated 
virtual host called COMSAT-WWV (what else?) with internet 


address [29,0,9,2]. This host is equipped with a Spectracom 
radio clock which normally provides WWVB time and date to 
within a millisecond. The clock synchronization mechanism 


provides offset and drift corrections for other hosts 
relative to this host; however, offsets up to an appreciable 
fraction of a second routinely occur due to the difficulty 
of tracking with power-line clocks in some machines. A 
table of the current offsets can be obtained using the 
following procedure. 


1. Connect to COMSAT-GAT host at internet address 
[29,0,1,2] using TELNET and local echo. 


2. Send the command SET HOST HOST. A table with one line 
per DCNET host should be returned. Note the entry under 
the "Offset" column for the WWV host. This contains the 
offset in milliseconds that should be added to all 
timestamps generated by either the COMSAT-GAT or 
COMSAT-WWV hosts to yield the correct time as broadcast 
by WWVB. 


3. Send the command SET WWV SHOW. A summary of datagram 
traffic is returned along with an entry labelled "NBS 
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time." The string following this is the last reply 
received from the Spectracom unit in the format: 


<code> DDD HH:MM:SS TZ=00 


where <code> is normally <SP> in case the WWVB signal is 


being received correctly or ? in case it is not. The 
DDD represents the day of the year and HH:MM:SS the time 
past UT midnight. The two digits following TZ= 
represent the time zone, here 00 for UT. 

4. Close the connection (please!). 

REFERENCES 

[1] ICMP 


Postel, J., “Internet Control Message Protocol", RFC 777, 
USC/Information Sciences Institute, April 1981. 


[2] GGP 


Strazisar, V., "How to Build a Gateway", IEN 109, Bolt 
Beranek and Newman, August 1979. 


DCNET Internet Clock Service PAGE 5 


Following is a specification of the ICS header in PDP11 
code: 


; GGP/ICMP Header 


. = 0 

GH.TYP: - BLKB 1 Message type 

GC.RPY = 0 ;Echo reply 

GC. UPD = 1 ;Routing update 

GC .ACK = 2 ;Positive acknowledgment 

GC.DNR = 3 ;Destination unreachable 

GC. SQN = 4 ; Source quench 

GC.RDR = 5 ; Redirect 

GC. ECH = 10 ;Echo 

GC.STA = 11 ;Net interface status 

GC . NAK = 12 ;Negative acknowledgment 

Gc.TIM = 15 ;Timestamp 

GC.TRP = 16 ;Timestamp Reply 

GH.COD: .BLKB 1 ;Message code 

GH.SEQ: .BLKW 1 ; Sequence number 

GH. HDR = : ;Beginning of original 
;internet header 

GH.ORG: .BLKW 2 ;Originating timestamp 

GH.REC: .BLKW 2 ;Received timestamp 

GH.XMT: .BLKW 2 ; Transmitted timestamp 

GH. LEN = 2 ;End of timestamp header 

Note that all PDP11 word fields (.BLKW above) are 
"byte-swapped," that is, the order of byte transmission is 


the high-order byte followed by the low-order byte of the 
PDP11 word. 


